This is an interesting scenario! It seems to suggest we should not follow the exact same behavior here as MuJoCo because the cost of the thread divergence is higher than the cost of the occasional extra solver step. That's my read at least.

I would suggest holding off on this and revisiting after we implement logging and measuring solver statistics, because then we can get a really good intuition on how early returning relates to step perf and the tradeoffs for this kind of thread divergence.

@thowell let's close this for now unless you're planning to come back to it soon?

@erikfrey the pr is updated with a simplified warmstart option for the solver

@thowell maybe in this same PR we should do some testing and compare solver iterations for MuJoCo Warp vs. MuJoCo C.

My expectation is that we are close to the number of solver iterations compared to MJC, let's say at most 1 more solver iteration for constraints that converge quickly, maybe a a few more for solutions that take a lot of iterations to converge quickly. And that warmstart helps as much in MJWarp as it does in MJC. Do you want to do that analysis over a few scenes?

Maybe as part of that analysis we should add printing solver stats to mjwarp-testspeed - WDYT?

@thowell what's the status of this PR?

@erikfrey the changes in this pr are now quite minimal, essentially just an option to initialize the solve qacc with qacc_smooth instead of qacc_warmstart. my preference would be to merge this pr as-is and then investigate solver iterations for difference scenarios in the future.